home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / hardware-part1 / 3252 / text0000.txt < prev   
Encoding:
Text File  |  1996-08-05  |  8.9 KB  |  167 lines
  1.  
  2. In article <4egg3n$grp@news.sdd.hp.com> Jeff Grimmett writes:
  3. > dalec@zorro.amitrix.com (Dale Currie) wrote:
  4. > 
  5. > >Nevertheless, in this instance, the above statement is correct as stands,
  6. > >and applies to all standard SCSI systems.
  7. > 
  8. > OK, read my post to Warren.  I don't know WHO is responsible, but I want 
  9. > to dispel the illusion that we're talking about a _standard_ SCSI system. 
  10. > If it were standard, the need for the technical bulletin would not be 
  11. > evident, neh?
  12.  
  13. Yes, saw a bunch of them, got a little toasty for a bit.  Sheesh! I didn't
  14. intend to start a war.  Obviously they needed technical bulletins to bring
  15. the problems to the attention of the appropriate people, unfortunately
  16. neither dealers or developers up here ever saw very many of them, and I
  17. won't go into the why's of that.
  18.  
  19. > If the A3000 early revision motherboard were standard, I do not believe 
  20. > we would be having this conversation.  I am speaking of a specific case, 
  21. > here, not SCSI in general, and I appologize if I have in any way given 
  22. > that impression.
  23.  
  24. Not a problem, it is apparent that we have a slightly different view of it.
  25. You seem to view the defective boards as non-standard, where I tend to
  26. think of them as a standard design that had some manufacturing flaws which
  27. put them out of spec.  AFAIK, all of them can be corrected.
  28.  
  29. > >Interesting, I didn't realize they changed that fast, as it took a little
  30. > >longer than that for them to filter through the chain.  I have a 7.3 which
  31. > >has no problems I've found yet, other than possible Z-III defects in the
  32. > >daughter board that I have not had time or need to check out. 
  33. > 
  34. > 7.3, eh?  You must have bought BEFORE power-up, or else mine was 7.3 (no 
  35. > way to find out, it went back to CBM the same day my rev 9 arrived).
  36.  
  37. Seems to me it was just at the beginning, but I could have got old stock
  38. that had not been rotated.  Who knows!
  39.  
  40. > My impression is that the 3000 was pushed to market a bit too fast.  
  41. > There are a lot of indications.  It was released before the OS was 
  42. > complete -- thus the original 2.01 KS/WD disks, the 1.4 beta ROMS, and 
  43. > the softkick (IMO, I like it, but they didn't see it that way).  The 
  44. > minitower on many of the earlier models was wired backwards.  The rom 
  45. > sockets were in many early models labeled backwards.
  46.  
  47. I won't argue that, mine came with 2.03 if I remember right.  It's still a
  48. softboot machine, I like it that way as well.  I knew about the rom socket
  49. labels, but do you mean the rom towers on some were defective, or just had
  50. to have the roms plugged in wrong way around?? Talk about twisted logic. :-)
  51.  
  52. > Every indication I get from this is that the rev 9 motherboard was well 
  53. > into pre-manufacturing stage by the time the 7.x board hit the streets, 
  54. > but not yet ready to be manufactured.  I do not think they released the 
  55. > 7.x motherboard, took a break, then set out to redesign the board and got 
  56. > it through the entire process in the first six months of the machine's 
  57. > availability.
  58.  
  59. Certainly not in that length of time.  There must have been a great deal of
  60. pressure from marketing due to the sales potential.
  61.  
  62. > >Possibly, but not necessarily.  In my experience, it depends on whether
  63. > >the person writing it knows what they're doing or is just regurgitating
  64. > >what they've been fed.  :-)  Production changes are sometimes made for
  65. > >reasons that may not be technically correct, and C= certainly did that on
  66. > >more than one occasion.  They would have to keep track of all changes and
  67. > >combinations of drives used, etc., then document them all and the effects
  68. > >of each.  It doesn't seem as though they did a very good job of that.
  69. > 
  70. > What I've seen indicates that they came from one or two points at CATS, 
  71. > not several disassociated engineers in several different places.  If they 
  72. > had a clear chain of command there, it would be not too difficult to 
  73. > filter all changes back to one location for centralized documentation. 
  74. > All this proves nothing, of course, and is based solely on what I've 
  75. > experienced -- I don't care to try to reverse-engineer the process, as 
  76. > I'd end up filtering it through what I consider the correct process.
  77.  
  78. My impression is that their testing processes were not adequate, but then
  79. hindsight will always tell you that.  ;-)  I would dearly love to see some
  80. documentation on all the changes that were made, _and_ have a copy of it.
  81.  
  82. > >Lt730's, SQ105's and some Maxtors come to mind as being a little picky
  83. > >about bus noise and proper termination, particularly the latter 2.  There
  84. > >are no doubt others, and running it in syncronous mode will usually make
  85. > >any deficiencies obvious fairly quickly.
  86. > 
  87. > I've got two Maxtors at home, neither seems to object :-)  As for sync 
  88. > mode, let me point out that the A3000's SCSI controller does not meet 
  89. > spec for sync transfer mode.  You can either enable all, or none.  If ONE 
  90. > drive on your bus does not properly support it, you'll have problems, 
  91. > more than likely.
  92.  
  93. That's why I said some Maxtors.  I think every drive manufacturer has made
  94. a few models that can be troublesome, or don't get along well with certain
  95. others on the same bus.  The sync mode AFAIK, meets spec for the controller
  96. chip used. The 33C93A is intended to be a low cost syncronous transfer chip
  97. and that's what it does, it's either on or off.  It is up to the drives to 
  98. handle it properly, and some (mostly older) do not.  One of the reasons I
  99. picked the Sony CD drive was because it did support sync mode.
  100.  
  101. > >Ah well, I was referring to the design, not goofups in the assembly, but
  102. > >there certainly were some of those.  From the discussions I've seen here
  103. > >over the years, it looks like some of these abberations have a regional
  104. > >basis to them, possibly due to the way they were batched for shipping.
  105. > 
  106. > A very distinct possibility that I won't deny at all. I feel maybe 
  107. > perhaps I didn't give the right example, though.  I wasn't intending to 
  108. > say that "only manufacturing flaws" could be considered as such an 
  109. > abberation.  ANY unintended behavior can be considered to take the 
  110. > machine out of spec within the framework OF that spec.  Thus, if the 
  111. > issue of termination on the 3000 is intended to correct for an unintended 
  112. > impedence matching problem (and this is completely supposition, there was 
  113. > no information in the referred bulletin as to WHY they insisted on not 
  114. > removing the terminators), the unintended impedence matching problem is 
  115. > the abberation, the driving force that takes these 3000s out of spec.
  116.  
  117. Agreed. They may simply have picked a cost effective solution that worked
  118. with the components/drives/etc. being used at the time.
  119.  
  120. > >I don't doubt you, and in the end, as I'm sure you know well, it's what
  121. > >works that's important.  Then again, as someone else pointed out, people
  122. > >have slightly different ideas about what "reliable" means.  I define it as
  123. > >being able to run almost continous transfers for hours or days at a time
  124. > >with no errors or problems.
  125. > 
  126. > Would running the system 24 hours a day for years without break as a BBS 
  127. > be considered sufficient punishment? :-)
  128.  
  129. Definitely, although I was referring to a test transfer loop, a busy BBS will
  130. certainly provide a thorough stress test for both durability and reliable
  131. operation.
  132.   
  133. > >Obviously, and there is no doubt the desktop service manual left something
  134. > >to be desired, at least the ones that were available up here.  I bought
  135. > >them at various times from when they first came out to just before C= died,
  136. > >and always got the same one.  The 3000T's manual is much better.
  137. > 
  138. > Bummer!  That more or less means to me that the schematic in the back of 
  139. > my 3000 manual is every bit as accurate as any other... it's a shame that 
  140. > they didn't rev the manual.  It's times like this that I regret not 
  141. > bribing the techos at one of our local stores to copy the things and pass 
  142. > them to me.
  143.  
  144. And I regret not bypassing C= Canada's aledged developer support and going
  145. straight to CATS sooner than we did.  We'd probably have got more docs.
  146.  
  147. > >From what the software guys that write CD drivers tell me, they are
  148. > >their worst nightmare, as every time a new model comes out they seem to
  149. > >twiddle with the firmware and format of the SCSI commands. 
  150. > 
  151. > Yeppers.  If anyone has a question as to the validity of specs vs the 
  152. > resulting hardware, one has to look no further than the current modem 
  153. > market.  Now THERE is a field I'd hate to work in...
  154.  
  155. Oooh, yes, nothing more annoying than trying to fax a critical document to
  156. someone when it won't connect or sends/receives garbage.
  157.  
  158. -- 
  159. Cheers,
  160. ---
  161. +    _       ____________   tm    Dale Currie    ____    ___     _      +
  162. |   /.\    ..     | __    \ /  dalec@amitrix.com    / __[___]__  T   tm |
  163. |  /___\  /\/\  | | |_) |  X  support@amitrix.com  /    (o.o)    |      |
  164. | /     \/ ^^ \ | | | \ | / \  Edmonton AB Canada /     `-^-'    |      |
  165. |/ - D E V E L O P M E N T - \      AmiTrix      /___ Z O R R O  I N K !|
  166. +    ---------------------     Technical Support      ----------------  +
  167.